Methods for executing programs described in high-level languages on computers are generally roughly classified into two major categories: the compiler method and the interpreter method which will be described below. Furthermore, run-time translation that is a method adopting the advantages of both compiler and interpreter methods is known. As an example, in environments in which Java (trademark registered) can be executed, run-time translation technology, known as JIT (just-in-time) compiler, is widely accepted and put into practical use. The following techniques have been proposed as known techniques regarding run-time translation.
For example, an installer having a CPU and a memory and executing an abstract object program by means of the CPU has been proposed (see JP-A-10-254712). The installer has means for receiving the abstract object program in an intermediate language format not dependent on computer's type, means for generating a machine language program on the memory from the received abstract object program, and means for causing the CPU to execute the generated machine language program immediately after the generation.
In addition, an information processor having plural registers, an instruction execution portion for executing a first format instruction as native instructions, and an instruction converting circuit has been proposed (see JP-A-2004-30222 (corresponding to US2004/3204A1)). When the first program written in a second format is executed, the information processor can be operated either in a first mode or in a second mode. In the first mode of operation, a first instruction set contained in the first program is converted into the first format instructions by the instruction converting circuit and executed. In the second mode of operation, a second instruction set contained in the first program is converted into the first format instructions by conversion software written in the first format instructions and executed. When the mode of operation is switched between the first and second modes, a transient mode of operation is introduced. Transfer of data between at least one of the registers and the instruction converting circuit is performed in parallel with the operation for switching of mode of operation.
Furthermore, a run-time program translation method for interpreting a source program or intermediate language program common to plural computers and translating the program into a machine language program native to each computer has been proposed (see JP-A-10-240546 (corresponding to US2001/11369A1)). Interpreting means for interpreting the source program or intermediate language program and program translating means for translating each individual module of the source program or intermediate language program into a machine language program are provided. The interpreting means counts the number of executions of each module during interpretation of the source program or intermediate language program and creates data about the frequency of the execution. The program translating means selects the module executed most frequently from the data about the frequencies of executions concurrently with the interpretation of the source program or intermediate language program done by the interpreting means. The module is translated into a machine language program.
The well-known, general run-time translation technique is first described below while citing the description of the “prior art” of Patent Reference 1 after describing the compiler method and the interpreter method which are key techniques, because the concept shown in the “prior art.” of Patent Reference 1 is hardly varied today.
In the compiler method, a program described in a high-level language is converted into a machine language program for the computer to be run. Then, the converted machine language program is directly executed. On the other hand, in the interpreter method, a language (intermediate language) different from the machine language for the computer to be run is set. Another program (interpreter) for interpreting the intermediate language on the computer to be run is previously prepared. The program written in a high-level language is converted into an intermediate language program, which in turn is executed by the interpreter.
The advantage of the compiler method over the interpreter method lies in the high speed of execution of programs for the following reasons.
(Advantage 1 of the Compiler Method)
The interpreter method needs assignment to processing steps corresponding to individual intermediate codes and computation of addresses of operands, in addition to execution of machine language corresponding to an intermediate language. Meanwhile, the compiler method does not need them because machine language is directly executed.
(Advantage 2 of the Compiler Method)
In the compiler method, omission (optimization) of processing taking account of the context of the program and the characteristics of the executing computer is possible.
On the other hand, in the interpreter method, the interpreter itself has versatility regarding intermediate language programs. Therefore, the interpreter simply executes the intermediate language program intact. Omission of processing taking account of the context of the program cannot be done. Furthermore, the characteristics of the executing computer are not reflected in the intermediate language program. Therefore, it is impossible to increase the speed of processing, for example, by mapping certain variables described in a high-level language into a register in the target computer.
The compiler method, however, has disadvantages compared with the interpreter method.
(Disadvantage 1 of the Compiler Method)
Each type of machine needs a compiler for converting a source program into a machine language program. The amount of compiler developed is increased. Besides, it is necessary to perform maintenance and expansion according to each individual machine type. This increases the overheads associated with maintenance and expansion.
(Disadvantage 2 of the Compiler Method)
Where the same program is executed on plural machine types, each individual machine type needs a separate compilation for conversion from a source program into a machine language program. This produces a large amount of overhead in management of machine language program.
(Disadvantage 3 of the Compiler Method)
In an environment where plural machine types are connected by a network, plural machine language programs corresponding to the same program are necessary for the plural machine types. This presents problems in managing versions and controlling the disk space. In addition, it is difficult to execute the same program distributively.
(Disadvantage 4 of the Compiler Method)
In some systems actually in operation, only a machine language program is used for operation; there is no source program. In such a system, it is difficult to switch or modify the machine type constituting the system. Furthermore, as the hardware technology is improved, computer architectures can be brought to a higher level with greater ease. However, in order to inherit the resources of machine language programs, strong limitations are imposed on changing of architecture.
Accordingly, where emphasis is placed on decrease of run time, the compiler method is more advantageous but results in demerits in terms of maintenance and operations as described above. Consequently, it has been necessary to use both the compiler and interpreter methods properly.
As a measure for mitigating the tradeoff between the aspect of maintenance and operation and the aspect of speed, a system making use of the advantages of both compiler and interpreter methods has been developed. This is the run-time translation (hereinafter referred to as “Method 1”).
Method 1 adopts an intermediate language program not dependent on certain computer machines as the aspect of maintenance and operation. When the intermediate language program is executed, it is converted into a machine language program for the target computer to obtain higher speed. In an environment where a Java (trademark registered) program can be executed and there is a run-time JIT (just-in-time) compiler, if the run-time compiler (run-time translator) performs dynamic compilation, the result of the run-time compilation (run-time translation) is stored in memory, and the intermediate language is subsequently executed, then the compiled native codes (machine codes) are executed.
Furthermore, a method of solving the disadvantage of the interpreter method in terms of speed by increasing the speed of the interpreter method (execution of intermediate language translation) itself has been developed. Especially, it is known that addition of hardware-based speed increase-assisting mechanism produces great speed-increasing effects. One example uses a bytecode accelerator (hardware accelerator) for converting a stack-based intermediate language (bytecodes) into register-based instructions as described in the “prior art” of Patent Reference 2. The speed is increased by executing the intermediate language directly by the hardware while the interpreter method is retained (hereinafter referred to “Method 2”).
In Method 1 described above, speed increases are achieved by software (run-time translation). On the other hand, it can be said that Method 2 achieves speed increases by hardware. These two methods, which mitigate the tradeoff between the compiler and interpreter methods in terms of the aspect of maintenance and operation and the aspect of speed, are common in that they can greatly improve the execution speed compared with the prior art software-based interpreter method. There is nothing to choose between these two methods.
The advantages and disadvantages of Method 1 (improved speed owing to software (run-time translation)) are as follows. It is known that where run-time translation is used, there arise the disadvantages that the load on the CPU is increased by compilation at run-time (generally known as run-time compilation) and that the size of the memory necessary to store the generated machine language program is increased. It is also known that the tendency that such CPU load and the amount of used memory are increased hinders application of a run-time program translation.
This disadvantage is mitigated by using profiled, run-time translation (i.e., evaluating (profiling) the frequency of execution and compiling only those portions which are executed at high frequency at run-time) as in the technique described in Patent Reference 3. However, not all of the disadvantages are removed.
Meanwhile, in this method, limitations due to the type of intermediate language, or the drawback with Method 2 (described later), do not occur. This constitutes an advantage.
The advantages and disadvantages of Method 2 (increased speed by hardware (bytecode accelerator)) are as follows. As mentioned in the “problem to be solved by the invention” of Patent Reference 2, in a case where hardware for converting an intermediate language into the native language (hereinafter referred to as CPU instructions or machine language) of the microcomputer that is a target during execution is used, only some intermediate languages are supported because it is difficult to execute every intermediate language by hardware. Although it is ideal to be able to convert every intermediate language by hardware, only some intermediate languages are supported, for the following reason. Some intermediate languages have complex functions. If such languages are converted, one intermediate code corresponds to tens to hundreds of CPU instructions. Therefore, if all the intermediate languages should be processed by hardware, the size of the hardware is increased excessively.
Accordingly, there are usually some kinds of processing which cannot be processed at increased speed by hardware. Those kinds of processing are treated by the prior art interpreter. Therefore, the speed-increasing effect is achieved only partially. This constitutes a disadvantage.
Meanwhile, unlike run-time translation using a compiler, the amount of processing is not increased during compilation. Also, any additional area for storing the result of compilation is not necessary. These constitute advantages.
In view of the foregoing, it can be considered that the execution speed can be improved more easily by making the run-time translation and bytecode accelerator complement each other.
For example, a method in which a subject of run-time translation is selected according to the execution frequency is now discussed. The subject (bytecodes) treated by the interpreter is passed through the bytecode accelerator and so those portions which are not subjected to run-time translation are also increased in speed. Therefore, it can be said that run-time translation coexisting with the bytecode accelerator is more adapted for increased speed than run-time translation used with no bytecode accelerator.
Where run-time translation coexisting with a bytecode accelerator is compared with a configuration in which only a bytecode accelerator exists and there is no run-time compiler, intermediate codes not supported by the bytecode accelerator are contained in the intermediate codes dynamically compiled by the compiler. This is advantageous for increase of speed.
During discussion of the combination of a software-based speed-increasing configuration (run-time translation) and a hardware-based speed-increasing mechanism (bytecode accelerator) as described above, we have realized that this combination creates a tradeoff between the power consumption and execution speed.
However, in the prior discussion of run-time translation, overhead due to the load imposed by the compilation itself delays local processing as occurring at startup. Also, it has been considered that there is a problem from a viewpoint of memory consumption. However, the overhead has not been regarded as problematic from a viewpoint of power consumption, for the following reason.
Where run-time translation is used, the execution speed is much higher (several times to ten times or higher) than where run-time translation is not used. The CPU load for the same amount of task is reduced, i.e., the number of dynamic steps is reduced. As a result, a power-saving effect is rather produced.
However, if an execution environment where a bytecode accelerator can be utilized effectively in interpreting an intermediate language is available, the overwhelming priority of the execution speed of run-time translation disappears. Therefore, increase in the power consumption due to overhead of the run-time translation tends to become conspicuous. Compared with the case where execution is performed using only a bytecode accelerator, combined use of run-time translation and a bytecode accelerator may incur a disadvantage in terms of power consumption (i.e., increase in power consumption), though this combined use is advantageous in terms of execution speed.
Accordingly, in view of the foregoing problems, the present invention has been made. It is a main object of the present invention to provide information processor and information processing method which can vary the allocation ratio between run-time translation and interpretation of intermediate language and suppress the power consumption while maintaining an appropriate execution speed.